Determining Identity Of Individuals Using Authenticators

ABSTRACT

Systems are provided that allow users to access resources in a manner that addresses inherent deficiencies in existing authentication systems. During a typical authentication process, the system may connect the user to one or more authenticators in real time through a variety of communications channels so that the authenticators may verify that the user is who he/she purports to be. In this way, a user may be authenticated and allowed to complete transactions that require access to protected resources/transactions. In some embodiments, the system may automatically identify authenticators for a user via an onboarding process by searching the user&#39;s electronic files, accessing social and professional networking sites, searching one or more credit reporting databases, or other such means. Based upon the determinations made by the authenticators, and other factors, such as the trust scores assigned to authenticators, an authentication engine may be used to calculate a confidence score regarding the user&#39;s identity that may be utilized in determining whether to grant the user access to protected resources/transactions.

RELATED APPLICATION

This application is a continuation of U.S. application Ser. No.15/231,298, filed Aug. 8, 2016 which is a continuation of U.S.application Ser. No. 14/530,168, filed Oct. 31, 2014, which claims thebenefit of U.S. Provisional Application No. 61/898,891, filed on Nov. 1,2013. The entire teachings of the above applications are incorporatedherein by reference.

BACKGROUND

When information systems restrict access, controlling the authenticationof individuals can be extremely important to ensure that only authorizedusers are allowed to interface with such systems. User authenticationmay be required to authenticate or verify a user or device in order to,for instance, allow access, approve a transaction, reset a password,grant authority to others, allow access to a physical resource connectedto the device (e.g. door lock), and the like.

Traditionally, service providers have relied on a username/password orPIN to authorize access. More recently, industry practice has veeredaway from reliance on such knowledge factors alone and instead movedtoward multi-factor authentication. Multi-factor online authenticationtypically requires a user to enter a username and password, as wellsatisfy one or more authentication factors. There are generally threegeneral types of authentication categories: a knowledge factor (e.g.something only the user knows, such as a password, challenge response),a possession factor (e.g. something only the user has, such as a cellphone), and an inherence factor (e.g. something only the user is, suchas face/voice/fingerprint matching).

Even with multi-factor authentication, the user typically has toremember his or her username and password. Often, with an increasednumber of different accounts a user may have with different serviceproviders, a user may forget knowledge based authentication informationassociated with the various accounts. To address this, manyauthentication systems are configured to enable users to reset or emailpasswords and provide hints to aid the user's responses to knowledgebased queries.

SUMMARY

While reliable methods for authentication exist, issues remain. Userauthentication based on multi-factor identification, such as ausername/password confirmation combined with SMS confirmation andbiometric fingerprints, for example, may be reliable, but typically lackflexibility, are susceptible to theft or misappropriation, and can beinconvenient to both the service provider handling the authenticationprocess and to the user attempting to access to the service provider'sservices.

The type of factors required are often implemented and imposed by theinformation service provider. Implementation of the multi-factorauthentication protocols can burden the service provider by, forexample, imposing expensive business process reengineering andmaintenance of its systems to ensure that its security protocols arerobust. Further, multi-factor authentication protocols can burden usersrequesting access by forcing the users to comply with potentially rigidauthentication requirements.

Users typically have a multitude of online accounts, which often causesusers to struggle to recall their responses to all of the knowledgefactors that need to be satisfied for authentication, especially if itis a password that is infrequently used or is frequently-changed.Further, such knowledge based factors are easily compromised with keyloggers that can capture, for instance, a username and password typed onthe user's device. In addition, hackers can use phishing and pharmingtechniques for the purpose of getting such knowledge basedpersonal/confidential information from the users (i.e., personal,financial or password data). Thus, knowledge based factors can be bothburdensome for the user and unsecure.

The burden on users to recall such knowledge based information can bealleviated and information security can be improved by relying oninherence factors, such as biometrics, to authorize access. Whileinherence factors are in many respects more secure than knowledge basedfactors, such inherence factors (e.g. voice, fingerprint, iris, vein,face, etc.) can be compromised by hacking the identification system.Even with a robust identification and access management system that maybe capable of thwarting hackers, such systems can be cost prohibitive toimplement.

Authentication using knowledge based and inherent factors has anotherinherent flaw. Both methods rely on stored values that, even encrypted,are susceptible to theft or misappropriation. The theft of biometricinformation (e.g. an iris scan), in particular, may cause significantproblems because due to its inherent uniqueness and permanence, the usercannot change the biometric data, as the user could change a password(e.g. user cannot change to another iris).

Thus, implementing an identity and access management solution requires adelicate balance between cost, and providing robust security, andusability. In today's dynamic global environment, finding that balancefor an identity and access management solution can mean the differencebetween the success and failure of a new product or even a new company.The currently available information security schemes are generallyunable to provide a security solution that satisfiesbusiness/operational security requirements, while providing afuture-forward scalable, cost effective solution capable of providingstrong security and being user friendly.

Some example embodiments of the present invention provide improvedsystems, methods, and computer program products to allow auser/requestor to perform transactions that require accessing protectedresources in a manner that can eliminate the deficiencies in knowledgeand inherent based solutions of the past. For example, some of theembodiments provided allow a user to identify human authenticators whoknow the user well. Then during the authentication process, the systemmay put a requestor purporting to be the user in live contact with theauthenticators, such as a video conference, in which the authenticatorsmay interact with the requestor to confirm whether the requestor isindeed the user that they know well.

In an example embodiment, the user may register to setup an account withthe authentication system of the present invention to performtransactions that require accessing the resources protected by thesystem. In these embodiments, the user may, by means of a requesthandler or application, transmit a registration request to theauthentication system to be received by an authentication enginecomponent of the system. The request may be communicated over variousnetworks, including an out-of-band network. In some embodiments, theauthentication engine may be implemented on a trusted platform module,and in other embodiments, the authentication engine may not be aseparate physical server but an integrated part of a virtual cloudnetwork. In some embodiments, the authentication system may be aninteractive voice response (IVR) system, in which the authenticationengine is implemented as an IVR device coupled to a telephony server andthe registration request may be a voice communication requiringinterpretation by the IVR device.

The authentication engine may perform an initial confirmation of theuser's identity, which requires collecting data regarding the user. Insome embodiments, collecting data may include contacting individualsassociated with the user, checking context on social or professionalnetworking sites, or sending a letter or package to the user by someform of certified delivery. Collecting data may also include searchingthe user's electronic files, posing questions to the user to gatheranswers, and searching one or more credit report databases forinformation on the user. The data collected regarding the user may be inthe form of text, images, voice, video, or forensic data. Aftercollecting the data regarding the user, the authentication engine maydetermine whether to confirm the user's identity by calculating aconfidence score that takes into account some or all of the data.

As part of the example embodiment, the authentication engine maydetermine one or more authenticators capable of confirming the user'sidentity for performing subsequent transactions. The authenticators maybe third-party human trustees with a relationship to the user, the usermy means of one or more devices calibrated as part of the registrationprocess, or other third-party devices or services that may assist inconfirming the identity of the user. The authentication engine may storeinformation regarding the authenticators in records corresponding toeach authenticator. The records may be retrieved during a subsequenttransaction to contact one or more of the authenticators in order forthe one or more authenticator to confirm that a requestor attempting toperform a transaction using the user's account is the user. The recordscorresponding to an authenticator may contain contact information forthe authenticator, relationship information to the user, or verificationinformation to be used for the authenticator to confirm the user'sidentity. The data contained in the records may be in the form of text,images, voices, video, or forensic data.

In the same or a different example embodiment, a request may attempt toperform transactions that require accessing the resources protected bythe system. In these embodiments, the user may, by means of a requesthandler or application, transmit an authentication request to theauthentication system to be received by an authentication enginecomponent of the system. In response to receiving the request, theauthentication engine may retrieve account information for theregistered user indicated in the request. The requestor sending therequest may or may not be the registered user indicated in the request.Based on the retrieved account information, the authentication enginemay retrieve records corresponding to one or more authenticatorsselected to confirm the registered user's identity. The authenticatorsmay be third-party human trustees with a relationship to the user, theuser my means of one or more devices calibrated as part of theregistration process, or other third-party devices or services that mayassist in confirming the identity of the user. The records correspondingto an authenticator may contain contact information for theauthenticator, relationship information to the user, or verificationinformation to be used for the authenticator to confirm the user'sidentity.

In some embodiments, the authentication engine sends information fromthe records to one or more corresponding authenticators, by means of averification handler or application, to confirm whether the requestor isa registered user. The information sent to the authenticators from theauthenticator records may be in the form of text, images, voices, video,or forensic data. The information sent from the at least one record mayinclude questions presented to the requestors and corresponding answersmay be in the records to verify the requestor's answer. Theauthentication engine may also collect information during theauthentication process that may or may not be in the record to presentto the authenticators, present to the requestor, or both. Thisinformation may also be collected to compare against data in the recordsor against information provided by the requestor during theauthentication process. This information may include electronic files,information from social or professional networking sites, or informationfrom one or more credit report agencies.

The information presented to the authenticators may also be collected inlive or recorded format from the requestor during the authenticatorprocess. In some embodiments, the information may be collected in aconference call including the requestor and one or more authenticators.In other embodiments, the information may be collected in a series ofindividual calls between the requestor and one or more authenticators,or in a joint call with the requestor and one or more authenticators orsome combination of both. The information may be collected by theauthenticators asking the requestor questions, or the authenticators mayonly see and hear the requestor without interacting with the requestor.

Once the authenticators are presented with information regarding therequestor's identity, the authentication engine may determine whether toallow the user access to the secure resources based on a response fromat least one authenticator. The response from an authenticator may beexpressed as a confirm or deny response and may further include theauthenticator's level of certainty in the response. Based on theauthenticator's response, the authentication engine may calculate astatistical confidence score to determine whether to allow the requestoraccess to the protected resources. This score may be based on theconfirm/deny and level of certainty of each authenticators, but thescore may also consider the level of confidence in the authenticatorreporting the result. The confidence score may also reflect other datacollected regarding the user, such as data from the requestor'selectronic files, information on social or professional networkingsites, one or more credit report agencies, or forensic data collectedduring the authentication process from the requestor compared to data onrecord for the user. The authentication engine may weigh the calculatedconfidence score against a threshold level to allow or not allow therequestor to perform the transaction.

The communications between the requestor devices, authenticator devices,and authentication engine may be communicated over various networks,including an out-of-band network. In some embodiments, theauthentication engine may be implemented on a trusted platform module,and in other embodiments, the authentication engine may not be aseparate physical server but an integrated part of a virtual cloudnetwork. In some embodiments, the authentication system may be aninteractive voice response (IVR) system, in which the authenticationengine is implemented as an IVR device coupled to a telephony server andthe authentication communications may be voice communications requiringinterpretation by the IVR device.

In some example embodiments, the authentication systemself-authenticates a user to perform transactions which requireaccessing protected resources. The user may request the authenticationengine, or an IVR device in another embodiment of the invention, tocalibrate a primary device and one or more secondary devices to the userfor self-authenticating the user during a future authentication process.The calibration of each device may include such information as a meansto contact the device and means to identify the device. During theauthentication process, to confirm the identity of the requestor as theuser, the authentication engine may send a request to the primary deviceto identify at least one of the secondary devices to send authenticationdata. The user, by means of the primary device, may reply back to theauthentication engine with a means to identify one or more secondarydevices. If the response includes the identity of one or more of thesecondary devices previously calibrated at the authentication engine,then the authentication engine will transmit authentication data to theone or more secondary devices.

Once the authentication data is received at the one or more secondarydevices, the user needs to access the one or more secondary devices totransfer the data to the primary device to complete the authenticationprocess. The authentication data may be image, sound, video, text, orother such data. The one or more secondary devices are calibrated topresent the data in a form that can be transferred to the primarydevice. In some embodiments, the transferring of the authentication datato the primary device may be performed by repeating the information intoa microphone on the primary device, taking a photo of the data from theprimary device, typing the information into the primary device, ortransferring the data to the primary device using wireless modalities.In other embodiments, the authentication data received by one or moresecondary devices is in the form of a question and, instead oftransferring the authentication data to the primary device, an answer istransferred to the primary device. After the transfer is made to theprimary device, the primary device may compare the received datacompared against a known data accessible by the primary device, and ifthe data matches, the primary device may send a confirmation to theauthentication engine.

BRIEF DESCRIPTION OF THE DRAWINGS

The foregoing will be apparent from the following more particulardescription of example embodiments of the invention, as illustrated inthe accompanying drawings in which like reference characters refer tothe same parts throughout different views. The drawings are notnecessarily to scale, emphasis instead being placed upon illustratingembodiments of the present invention.

FIG. 1A is a schematic diagram of an example computer networkenvironment in which embodiments of the invention are deployed.

FIG. 1B is a block diagram of certain components of the computer nodesin the network of FIG. 1A.

FIG. 1C is a block diagram of the network of FIG. 1A configured in anexample embodiment as an interactive voice response (IVR) system.

FIG. 2 is a block diagram of an example system for authenticating users.

FIG. 3A is a flow diagram of an example user onboarding process.

FIG. 3B is an example interface showing pre-existing accounts that maybe linked during the onboarding process.

FIG. 4 is a flow diagram of an example user authentication process.

FIG. 5 is a flow diagram of an example confidence scoring process.

DETAILED DESCRIPTION OF THE DRAWINGS

A description of example embodiments of the invention follows.

Digital Processing Environment

Example implementation of a user identification system 100 (e.g.identity and access management solution) may be implemented in asoftware, firmware, or hardware environment. FIG. 1A illustrates onesuch example digital processing environment in which embodiments of thepresent invention may be implemented. Client computers/devices 150 andserver computers/devices 160 (or a cloud network 170) provideprocessing, storage, and input/output devices executing applicationprograms and the like.

Client computers/devices 150 may be linked directly or throughcommunications network 170 to other computing devices, including otherclient computers/devices 150 and server computer/devices 160. Thecommunication network 170 can be part of a wireless or wired network,remote access network, a global network (i.e. Internet), a worldwidecollection of computers, local area or wide area networks, and gateways,routers, and switches that currently use a variety of protocols (e.g.TCP/IP, Bluetooth®, ®, etc.) to communicate with one another. Thecommunication network 170 may also be a virtual private network (VPN) oran out-of-band network or both. The communication network 170 may take avariety of forms, including, but not limited to, a data network, voicenetwork (e.g. land-line, mobile, etc.), audio network, video network,satellite network, radio network, and pager network. Other electronicdevice/computer networks architectures are also suitable.

Server computers 160 may be configured to provide a user authenticationsystem 100 which communicates with authenticators to confirm arequestor's identity prior to allowing the requestor to access resourcesprotected by the authentication system. The server computers may not beseparate server computers but part of cloud network 170.

FIG. 1B is a block diagram of any internal structure of acomputer/computing node (e.g., client processor/device 150 or servercomputers 160) in the processing environment of FIG. 1A, which may beused to facilitate displaying audio, image, video or data signalinformation. Each computer 150, 160 in FIG. 1B contains a system bus110, where a bus is a set of actual or virtual hardware lines used fordata transfer among the components of a computer or processing system.The system bus 110 is essentially a shared conduit that connectsdifferent elements of a computer system (e.g., processor, disk storage,memory, input/output ports, etc.) that enables the transfer of databetween elements.

Attached to the system bus 110 is an I/O device interface 111 forconnecting various input and output devices (e.g., keyboard, mouse,touch screen interface, displays, printers, speakers, audio inputs andoutputs, video inputs and outputs, microphone jacks, etc.) to thecomputer 150, 160. A network interface 113 allows the computer toconnect to various other devices attached to a network (for example thenetwork illustrated at 170 of FIG. 1A). Memory 114 provides volatilestorage for computer software instructions 115 and data 116 used toimplement software implementations of authentication components of thepresent invention (e.g. an authentication/attestation agent/engine 240,request handler 210, verification handler 220 a, 220 b, andauthentication engine 240, interactive voice response (IVR) system 184,portal 194 of FIGS. 1C and 2).

Software components 115, 116 of the user authentication system 100 (e.g.FIGS. 1A, 1B, 1C and 2) described herein may be configured using anyprogramming language, including any high-level, object-orientedprogramming language.

The server may include instances of the authentication engine 240 (FIG.2), which can be implemented as a client that communicates to the server160 utilizing encrypted data packets (e.g. via SSL) and may compute aconfidence score that provides a measure of confidence about theidentity of a user of a computing device 150 based on, for example,communication with third party authenticators/attesters. For example,the system may include other instances of client processes executing onother client computers/devices 150, which allow theauthenticators/attesters to receive and send communications in relationto authenticating a requestor as a registered user. In some embodiments,the computing device 150 identification may be implemented via asoftware embodiment and may operate, at least partially, within abrowser session. In further web-based or app based exampleimplementations, a request to authenticate a user may be received via arequest handler 210, processed via an authentication agent/engine 240,as discussed in reference to FIG. 2.

In an example mobile implementation, a mobile agent implementation ofthe invention may be provided. A client server environment can be usedto enable mobile security services using the server 190. It can use, forexample, the XMPP protocol to tether a device authenticationengine/agent 115 on the device 150 to a server 160. The server 160 canthen issue commands to the mobile phone on request. The mobile userinterface framework to access certain components of the system 100 maybe based on XHP, Javelin and WURFL. In another example mobileimplementation for OS X and iOS operating systems and their respectiveAPIs, Cocoa and Cocoa Touch may be used to implement the client sidecomponents 115 using Objective-C or any other high-level programminglanguage that adds Smalltalk-style messaging to the C programminglanguage.

The system may also include instances of server processes on the servercomputers 160 that may comprise an authentication (or attestation)engine 240 (FIG. 2), which allow registering a user, selectingauthenticators/attesters for confirming a requestor is a registereduser, communicating with the authentications in regards to confirming arequestor's identity, and executing algorithms, such as statisticalalgorithms to compute confidence scores, to allow or deny the requestoraccess to resources protected by the system.

Disk storage 117 provides non-volatile storage for computer softwareinstructions 115 (equivalently “OS program”) and data 116 used toimplement embodiments of the system 100. The system may include diskstorage accessible to the server computer 160. The server computer canmaintain secure access to records related to the authentication of usersregistered with the system 100. Central processor unit 112 is alsoattached to the system bus 110 and provides for the execution ofcomputer instructions.

In an example embodiment, the processor routines 115 and data 116 arecomputer program products. For example, if aspects of the authenticationsystem 100 may include both server side and client side components. Inone example implementation of the system 100, an interactive voiceresponse system (IVR) and related components as in FIG. 1C may be usedto send messages to authenticators/attesters who have been selected toattest to the identity of a user. Computer readable software componentsof such an IVR system may be implemented, at least in part, in software115, 116.

In an example embodiment, authenticators/attesters may be contacted viainstant messaging applications, video conferencing systems, VOIPsystems, email systems, etc., all of which may be implemented, at leastin part, in software 115, 116.

In an example embodiment, the authentication engine/agent may beimplemented as an application program interface (API), executablesoftware component, or integrated component of the OS configured toauthenticate users on a Trusted Platform Module (TPM) executing on acomputing device 150.

Software implementations 115, 116 may be implemented as a computerreadable medium capable of being stored on a storage device 117, whichprovides at least a portion of the software instructions for the userauthentication system 100. Executing instances of respective softwarecomponents of the user authentication system 100, such as instances ofthe authentication engine, may be implemented as computer programproducts 115, and can be installed by any suitable software installationprocedure, as is well known in the art. In another embodiment, at leasta portion of the system software instructions 115 may be downloaded overa cable, communication and/or wireless connection via, for example, abrowser SSL session or through an app (whether executed from a mobile orother computing device). In other embodiments, the system 100 softwarecomponents 115, may be implemented as a computer program propagatedsignal product embodied on a propagated signal on a propagation medium(e.g. a radio wave, an infrared wave, a laser wave, a sound wave, or anelectrical wave propagated over a global network such as the Internet,or other networks. Such carrier medium or signal provides at least aportion of the software instructions for the present user authenticationsystem 100 of FIG. 2.

Interactive Voice Response (IVR) System

FIG. 1C is a block diagram of an example implementation of certaincomponents of the system 100 of FIG. 1A. In the example configuration inFIG. 1C, an interactive voice response (IVR) system is provided. In thisembodiment, the user authentication system 100 is based on interactivevoice response (IVR) technology. IVR is a telephony technology in whicha user uses a touch-tone phone, speech recognition, or a mobile app tointeract with a database to acquire information from the database or toenter data into the database. The requestor 172, by means of a voicedevice 174 (e.g. mobile phone, landline phone, video phone), may send arequest (e.g. make a phone call) for protected information (e.g. bankaccount balance). The request may be received by the telephony serversystem 182 through the telecommunication network 180. The telephonyserver 182, may access information contained in the request, such as thedestination phone number, and based on this information, may respond byprompting the requestor for security information (e.g. username,password, pin code). Once the user enters the security information, thetelephony server 182, transfers this information out a port to anapplication server 190, implemented using a conventional applicationserver computer platform and executing a standard application serveroperating system that provides for the execution of phone applicationprograms.

The application server 190 may then pass this information to thedatabase server 188 for further processing. The database server 188 mayverify that the security information corresponds to an active accountand provide this information back to the application server 190. Basedon this response, the application server 190 may decide that additionalsecurity information may be needed to confirm the identity of therequestor. The application server 190 may request additional informationfrom database server 188 or cluster of NFS servers 192, or may use aportal 194 to collect information from outside networks, such as theInternet.

Using the information received, the application server 190 may requestthe telephony server system to communicate across the telecommunicationnetwork 180 to contact an authenticator 178 by means of voice devices176 (e.g. mobile phone, landline phone, video phone) to confirm theidentity of the requestor. The telephony server may communicate with theauthenticator (or multiple authenticators by means of multiple devices)and the requestor in the same voice or video session using conferencecalling technology. In other embodiments using the IVR system, thecommunication may be in a series of phone calls between the requestorand each authenticator, or the requestor may not be included in thecommunication, but a third-party representative or device may beincluded instead. Based on this communication, the authenticator 178, bymeans of voice device 176, may communicate a response to the telephonyserver system 182 (e.g. using the device keypad, device app, or speech);the response may confirm or deny the identity of the requestor. Thetelephony server system 182 may transfer the response to the applicationserver 190 for processing and then, based on the response, theapplication server 190 may instruct the telephony server system to allowthe requestor access to the requested information.

The telephony server system 182 may execute a computer telephonyintegration application that, in combination with the voice packetizer186, preferably implements the interactive voice response (IVR) system186 that allows the telephony server system 182 to effectively handleand respond to the voice communications.

FIG. 2 is a block diagram of one example implementation of theauthentication system 100 according to an embodiment of the invention. Arequestor 205, by means of device 210, 150, 160, attempts to make anonline transaction which requires authentication to access virtual orphysical resources protected by the system. Device 210, 150, 160includes, but is not limited to, any computing or electronic device(e.g. personal computer, client processor, server processor, mainframe,wearable computing device such as Google Glass, laptop, tablet, mobilephone device, personal digital assistant, tablet, Bluetooth device,pager, land-line phone, camera, video camera, or any other network orcomputing device. The protected resources attempted to be accessed maybe assets, purchases, services, content, documents, or other suchresources, and may be accessed through websites, smartphone apps, radio,television, ATMs, or any other network accessible medium.

In the example authentication system, the requestor 205, by means of theuser device 210, may communicate across a network 230 to theauthentication/attestation engine or agent 240 to initiate the userauthentication process. In one embodiment, the user device 210 may be atelephony device, such as a mobile or landline phone, and theauthentication engine 240 may be a telephony server configured with aninteractive voice response (IVR) system. In another embodiment, thenetwork 230 may be a cloud such that the authentication engine 240 andmemory storage 245 are not separate physical servers but all part of thetelecommunication cloud network 180.

The requestor's transaction request may be transmitted to theauthentication engine 240 to initiate the user authentication process.The authentication process may determine that the requestor is a newuser that needs to be registered with the authentication system (e.g.setup an account), also referred to as onboarding. Alternatively, therequestor, by means of the requestor device 210, may initiate theonboarding process directly by sending a registration request to theauthentication engine, without attempting to perform authentication. Theonboarding process may then be initiated at the authentication engine240 to setup a user account for the requestor. As part of the onboardingprocess, the authentication engine 240 may store authenticator recordsin memory 245 accessible to the authentication engine. These recordscontain information that may be used to contact authenticators 215 a,215 b, by means of authenticator devices 220 a, 220 b, when a requestorattempts to access resources protected by the system. The authenticatorinformation may be provided from the user, or may have beenautomatically determined by the authentication engine by searching theuser's electronic files, accessing social and professional networkingsites, searching one or more credit reporting databases, or other suchmeans.

The requestor, instead, may have already registered as a user of thesystem but needs to be authenticated because: the system may requireauthenticators to confirm the identity of the requestor, the requestorforgot their login information (e.g. username, password), therequestor's login information expired, the particular transactionimposes heightened authentication, or for any other reason. Furthermore,the requestor's transaction may be part of ongoing transactions to thesame resources, such as accessing secure images or documents stored inthe cloud, or as a one-time transaction, such as registering for acredit card. However, the requestor may only be purporting to be aregistered user in an attempt to gain unauthorized access to theprotected resources for illicit purposes, such as to damage or steal theprotected resources, and in such case should not be allowed access tothe system.

If the requestor 205, by means of the requestor device 210, indicatesthat he is a registered user of the system, whether the requestor isregistered or not, the authentication process may be initiated at theauthentication engine 240 to confirm that the requestor is theregistered user. As part of the authentication process, theauthentication engine 240 may retrieve authenticator records from memory245 and select one or more authenticators 215 a, 215 b attest to therequestor's identity. Once the authenticator process selects one or moreauthenticators, the authentication engine may communicate with theauthenticators 215 a, 215 b, in serial or parallel, by means of theauthenticator devices 220 a, 220 b. The authenticator devices 220 a, 220b may include any computing or network device 150, 160, Bluetoothdevice, pager, land-line phone, camera, video camera, and the like.

The authentication engine 240 may communicate text, image, audio, video,forensics, or other such data to the authenticators as part of theprocess to confirm the requestor's identity. The authentication enginemay communicate the data in real-time, such as in a video conferencewith the requestor present, or in delayed medium, such as in a textmessage or email. The one or more authenticators 215 a, 215 b, by meansof authenticator devices 220 a, 220 b, then may respond to theauthentication engine 240 to confirm or deny that the requestor is theregistered user who he/she proclaims to be, and the authenticationengine 240 may evaluate the one or more responses from theauthenticators to either grant or deny the requestor access to thesecure resources protected by the system.

“Trusted” Authenticators

Each authenticator may be assigned a respective level of trust (or trustscore) by the system 100. For example, an authenticator may beconsidered highly “trusted” indicating that there is a high likelihoodthat authenticator provides accurate and trusted authentication. Trustfactors using third party data may be considered in assigning a level oftrust to an authenticator.

Example trust factors that may be considered in assigning a level oftrust (or trust score) to an authenticator may include whether theauthenticator is a 1st-degree connection of the requestor/user on asocial media site (such as LinkedIn), whether the authenticator is inone or more of the requestor's/user's social circles (e.g. friends orfamily circles on Google+), whether the authenticator has beenspecifically designated as a family member or someone that theuser/requestor is in a relationship with on a social networking profileof the requestor/user, whether the authenticator has recentlycommunicated with the requestor/user via email, social media, text orelectronic other means, and whether the requestor/user had specifiedthat the authenticator was trusted during the initial onboardingprocess.

Data models may be built for each authenticator associated with theuser/requestor, which are used to facilitate computation of theconfidence level/score. The data models may include statisticalinformation related to the authenticator. For example, a ratioindicating the frequency with which the requestor/user and theauthenticator communicate with one another, over a period of time, maybe included. A correlation index indicating the likelihood thatauthenticator is trusted, as compared to an average user profile of anuntrusted authenticator, may also be determined. In this way, theauthenticator trust factors, the determined communication frequencyratio, determined correlation index, and related data, may be factoredin to compute a trust level or trust score for the authenticator andused to build an associated data model for that authenticator.

User Onboarding Examples

FIG. 3A is a flow diagram of an example user onboarding processaccording to an embodiment of the invention. In this embodiment, a userrequests to register (onboard) with the authentication system 100 inorder to make one or more future transactions (or request access), whichrequire authorization. The authentication engine 240 receives a userrequest 312 from the user 205 by means of the user device 210, 150. Aspart of the onboarding process, the authentication engine 240 may firstperform an initial confirmation of the user's identity 314.

The requestor/user may choose to setup a new account with theauthentication system or may login using third party pre-existingaccounts (e.g. email, social networking, business) including, but notlimited to, LinkedIn, Gmail, Yahoo, Hotmail, Facebook, Twitter, Google,Dropbox, Quora, Pinterest, Vimeo, or Netflix. (See, e.g. FIG. 3B for anexample interface showing sign-in options to example pre-existingaccounts 340, 341, 342, which may be linked during the user onboardingprocess.) Preferably, several of the user' s/requestor's preexistingaccounts are selected and linked in the initial confirmation process asbeing associated with the user. Existing contacts and data associatedwith the requestor/user's social profiles may be accessed and stored bythe system during the onboarding process.

By linking third party pre-existing accounts, the authentication systemis able to gather third party held information and third party contactsassociated with the requestor/user, which can be used to augment theauthentication process of the user with a high degree of confidence.

To further facilitate confirming the user's identity, for instance, theauthentication engine may collect text, images, audio, visual, or otherdata from the user, in a variety of forms including, but not limited to,text, photos, voice prints, videos, or handwriting. The data may becollected in real-time during the onboarding process via linked thirdparty accounts or in delayed time from the user. For example, theauthentication engine may in real-time record the voice and images ofthe user during a video call, or may record answers to questions posedto the user during a phone call.

In another example, the authentication engine may request that the userupload or send recorded images, voice prints, videos, answers toquestions, or such to the authentication engine in a text messages oremail within a specific delayed period of time. The authenticationengine may also automatically collect data regarding the user byimporting the user's contacts, messages, calendar, social media data andother electronic data through any linked third party accounts.

In another embodiment, the authentication engine may also automaticallycollect data regarding the user searching the user's electronic files(e.g. phone/address book, phone record, text messages), searching one ormore credit reporting agency databases (e.g. Experian), or other suchmeans. The authentication engine may also have a third-party servicecollect data samples from the user, such as taking photos, voice prints,videos, handwriting samples, fingerprints, dental prints, blood, DNA, orany other such samples.

The authentication engine may use the collected data to confirm theuser's identity. The authentication engine may contact one or moreindividuals associated with the user, such as friends, family, schoolmates, colleagues, and present some or all of the collected data. Thecontacted individuals may have been provided by the user, or may havebeen automatically determined by the authentication engine by searchingthe user's electronic files, accessing social and professionalnetworking sites, searching one or more credit reporting agencydatabases (e.g. Experian), or other such means. The individuals may becontacted using delayed communication methods, such as a text message oremail, and sent some or all data collected during the onboardingprocess. The individuals may instead be contacted using livecommunication methods, such as a phone call, video call, conferencecall. The user may be present during the live communication and theindividuals may be able to interact with the user or may only be able tohear or see the user. A third-party (e.g. authentication systemrepresentative or device) may also or instead be present during the callto present data collected during the onboarding process to theindividuals.

The authentication engine may use other means to initially confirm theuser's identity as part of the onboarding process. The authenticationengine may communicate with virtual or physical devices to identify theuser. For example, the authentication engine may communicate with animage processing device to compare a picture or video collected from theuser against an image or video of the user obtained from a social orprofessional networking site. Om another example, the authenticationengine may search one or more credit reporting agency databases (e.g.Experian) to compare answers from questions posed to the user during theonboarding process against known (public or private) data regarding theuser.

The authentication engine may also communicate with third-party servicesto identify the user, such as credit reporting agencies (e.g. Experian).For example, collected data for the user, such as collected handwritingor blood samples, may be transmitted to a third party, such as aforensics lab. The third-party service may then analyze the collecteddata against known data for the user, such as from the user's medicalfiles or other forensic files, and communicate the results back to theauthentication engine.

In another example, the authentication engine may utilize traditionalmail or package delivery services (e.g. United States Postal Service,Federal Express, or United Parcel Service) to send a certified letter orpackage or similar service requiring positive identification fordelivery with receipt returned via the traditional mail or packagedelivery service or by automated means such as the data interfacesoffered by the delivery services to provide electronic confirmation. Therecord of the delivery may be used by the authentication engine toconfirm the user's identity, since the delivery service would onlyrelease the certified post or similar delivery to the user after visualverification of the user's identity. For example, a delivery service mayoffer a verified delivery option which, if selected on a data interface(e.g., check a box on data interface), would require the deliveryservice to check reliable identification (e.g. government issued ID)prior to releasing the mail or package. There may also be informationcontained in the certified post that the user must communicate back tothe authentication engine as part of the verification process. A similarverification procedure may be conducted through any other business ororganization that confirms an individual's identity prior to deliveringa product or service.

In a further example, the authentication engine may send an electronicnotary service (e.g., e-notary) a document with the user information tobe verified (e.g., name, address, birth date). The document may be sentto the service through electronic mail, a data interface, or other suchmeans. The service may receive the document and arrange for a notary tomeet the user (e.g., at the user's house, at the user's place ofbusiness, or at the notary service office). At the meeting, the notarychecks reliable identification for the user (e.g. government issueddriver's license or passport), then has the user sign the document andnotarizes the signature. The document is then returned to theauthentication engine in electronic format. The entire process may becompleted with the document in electronic format, or the document may beprinted, signed/notarized, and scanned back into electronic formatbefore transmitting back to the authentication engine.

For the onboarding process, the user may be assigned a respectiveconfidence score by the system 100. For example, a user may beconsidered highly “trusted” indicating that there is a high likelihoodthat the user is who he claims to be. The trust score may be calculatedbased on the level of trust of each individual confirming the user'sidentity. For example, the confidence score may be based on anindividual's relationship to the user (e.g. friend, family, orcolleague), how often an individual communicate with the user, whetheran individual is a 1st-degree connection of the user on a social mediasite, and based on confidence scores calculated for the individuals inregards to other accounts on the system. The confidence score may alsoinclude the other factors used in confirming the user's identity, suchas data verified by third-party devices and services.

As part of the onboarding process, the authentication engine may thenconfigure one or more authenticators for confirming future requestorsaccessing the system as the user are actually the user. An authenticatormay be a human trustee that has an association with the user, such asfamily, friends, colleagues, or school mates. The authentication enginemay retrieve authenticator data 316 corresponding to an authenticatorfrom various sources. The authentication data may be provided from theuser, or may have been automatically determined by the authenticationengine by searching the user's electronic files, accessing social andprofessional networking sites, searching one or more credit reportingdatabases, or other such means. The authenticators may or may notinclude the same individuals used to initially confirm the user'sidentity. The authenticators may also be virtual or physical devicesthat may confirm the identity of the user from textual, audio, visual,forensics, or other samples. For example, the device may be an imageprocessing device which compares a picture or video collected from theuser during onboarding against an image or video of the user capturedduring the authentication process. The authenticators may also be athird-party service, such as a lab, which may analyze data collected atonboarding, such as fingerprints or DNA, against data collected duringthe authentication process or from other user records, such as medicalrecords.

The authenticators may also include the user himself who can confirmhis/her own identity during future transactions through aself-authentication process. As such, the user may calibrate a primarydevice, such as a mobile phone, for the authentication engine to contactduring the authentication process. The user may then calibrate one ormore secondary devices, such as a mobile phone, tablet, computer, faxmachine, pager, or television, which may be used for self-identificationduring a subsequent self-authentication process. As part of calibratingthese devices, the user may specify the means of contacting the device,such as a phone number or web address, and a means for identifying thedevice, such as a nickname or serial code. During the authenticationprocess, one or more of the devices must be in close proximity to theuser because communications may need to be transmitted between theprimary and secondary devices to confirm the identity of the user.

The authentication engine may store authenticator data 318 related toeach authenticator as a record in memory 245 accessible to theauthentication engine 240. The authenticator records may be storedcompressed, hashed, encrypted or in another such digitally alteredformat. To create a record for an authenticator, the authenticationengine may request from the user or third-parties information related tothe authenticator. This information may include contact information forthe authenticator, such as phone number, email address, web address, andrules for contacting the authenticator, such as preferred method tocontact, times to contact, order to contact. The information may alsoinclude relationship information, such as how an authenticator knows theuser or for how long, and the type of verification information to bepresented to the authenticators to identify the user. The informationmay also include verification information to be presented to theauthenticator for confirming the authenticator's own identity. Theverification information (for both the user and authenticator) mayinclude text, images, audio, visual, or other data from the user, suchas text, photos, voice prints, videos, handwriting, or questions/answer.The verification may be collected in real-time, such during a videocall, or delayed time, such as images sent in an email or text messagein a specified period of time. The authentication engine may alsoautomatically collect data regarding the user by searching the user'selectronic files (e.g. phone/address book, phone record, text messages),accessing social and professional networking sites (e.g. LinkedIn,Facebook, Twitter), searching one or more credit reporting agencydatabases (e.g. Experian), or other such means. The authenticationengine may also have a third-party service collect data from the user,such as taking photos, voice prints, videos, handwriting samples,fingerprints, dental prints, blood, DNA, or any other such samples. Inregards to the verification information for the user, the informationmay or may not include the same information collected when initiallyconfirming the user's identity. The data records may also be stored in abitcoin block chain transaction, or similar technology, to be usedduring future authentication processes to verify that the data recordshave not been modified.

If the onboarding succeeded and the user's identity is confirmed at 320,then one or more authenticators are configured for authentication.Otherwise, the authentication engine may determine onboarding failed 322and the user may not attempt to access resources protected by theauthentication system.

User Authentication Examples

FIG. 4 is a flow diagram of an example user authentication process.

A requestor 205, by means of device 210, attempts to make an onlinetransaction which requires authentication to access protected virtual orphysical resources. The requestor's transaction request may then becommunicated to the authentication engine 240 to initiate theauthentication process to confirm that the requestor 205 is a registereduser of the system. The requestor's transaction request may includeaccount information, such as a username, password, pin code, or similarsuch information. The authentication engine may receive the transactionrequest 412, and using the information provided in the request,determine that the request is in regards to an existing user account fora registered user of the system 414. The authentication engine may alsodetermine that the information provided does not correspond to anyexisting user account and may either ignore the request, notify therequestor that the request is invalid, prompt the requestor to create anew user account, or take another such action. The request received 412may also be a registration request to create a new user account, and anembodiment of the onboarding registration process, such as theembodiment previously described, may be initiated to register therequestor. If the request is an authentication request in regards to anexisting user account, the authentication engine may start theauthentication process to confirm that the requestor is indeed theregistered user of the existing user account indicated in the request.

As part of the authentication process, the authentication engine may usethe information in the requestor's transaction request to retrieveauthenticator data records 416 corresponding to the user accountindicated in the request. The authenticator data records may have beencreated as part of the onboarding process for setting up the useraccount. The information from the data records may also have been storedin a bitcoin block chain transaction and the data records may becompared against the secure block chain data to verify that the datarecords have not been modified or tampered, whether mistakenly orillicitly. The authentication engine may consider the authenticator datarecords to determine one or more authenticators 220 a, 220 b to contactto confirm that the requestor is the registered user. The authenticatorrecords may indicate pre-selection criteria for selectingauthenticators, such as all authenticators are contacted, certainauthenticators are contacted (with the rest as backup), a methodologyfor selecting and ordering authenticators, or other such pre-selectioncriteria. The authenticator records may also indicate that only certainauthenticators are available for authenticating the requestor (e.g. timerestrictions or transaction type restrictions) based on informationstored in authenticator records. The authentication engine may then useone or more algorithms to select from the available authenticators. Forexample, the authentication engine may use probabilistic algorithms tocalculate a confidence score to statistically rank the availableauthenticators based on various factors, such as the frequency the usercommunicates with the authenticator, relationship type (e.g. family,school mate, colleague), degree of separation as calculated bythird-party sites (e.g. LinkedIn). In some embodiments, the confidencescores for each authenticator may already be calculated during theonboarding process and stored as part of the authenticator record foruse during the authentication process and updated from time to time orthe confidence score may be calculated in real-time as needed.

The authentication system may also support different security levels inwhich different transactions may require different levels ofauthentication based on various factors, such as the sensitivity of thedata being accessed or the risk of deviant behavior. As such, certainauthenticators may only be eligible for certain transactions based onthe confidence scores calculated for the authenticators. For example, anauthenticator may be eligible to confirm the requestor's identity for atransaction involving a bank account deposit but the same authenticatormay not be eligible for a transaction involving a bank accountwithdrawal. In addition, a greater number of authenticators may berequired for certain transactions based on the confidence scores.Furthermore, based on the required security level, only certainauthenticators may be eligible because of the methods for which thoseauthenticators are configured to interact with the requestor. Forexample an authenticator configured for video calls with the requestormay be selected instead of an authenticator configured for voice-onlyphone calls with the requestor. Based on such factors, theauthentication engine may select one or more authenticators to confirmthe identification of the requestor as the registered user.

Once one or more authenticators are selected, the authentication enginemay initiate communications 418 with the authenticators 420 a, 420 b, bymeans of authenticator devices 220 a, 220 b, to confirm the requestor'sidentity. If an authenticator is not available when the authenticationengine attempts to contact him, the authentication system may insteadcontact another authenticator or may use a reduced number ofauthenticators. For each of the available authenticators, theauthentication engine may select the mode of communicating with theauthenticator based on the information stored in authenticator records.Based on the selected mode, the communication may require certaincomponents to be present on the authenticator device 220 a, 220 b, suchas a camera, microphone, speaker, or video display. If the requestor isalso involved in the communication then the requestor's device may alsorequire such components. Based on the selected mode, the authenticationprocess may be conducted in real-time or over a deferred period of time.In a time delayed-deferred authentication example, if the mode is a livetelephone or video call, the authentication session occurs as areal-time conversation in which a decision may be made during theconversation on the identity of the requestor. Alternatively, forexample, if the selected modality is via email or text message, whichmay include an accompanying image, video, or voice sample, the decisionmay be deferred and may allow the authenticator to respond within apredetermined or specified amount of time.

The authentication process may select certain data to present to one ormore authenticators to confirm the requestor's identity as the user. Theauthentication process may select to present text, images, video, audio,forensics, questions/answers, and other such data to the authenticator.The data may be stored data from the authenticator record, may berequested from the requestor as part of the authentication process, orsome combination of both. The data may also be automatically collectedduring the authentication process by the authentication engine searchingthe user's electronic files (e.g. phone/address book, phone record, textmessage), accessing social and professional networking sites, orsearching one or more credit reporting agency databases. The image,audio, video, and other such data may be previously recorded, either atthe time of user registration or earlier in the authentication processand played back to the authenticator for verification purposes. Theaudio, video, and other such medium may also be live in which one ormore microphones, video cameras, or other such equipment may bestreaming sounds and images of the requestor, the requestor'ssurrounding environment, or both to the authenticators for verificationpurposes. The live communications may allow the requestor 413 tointeract with the authenticators 420 a, 420 b, such as to ask questions,or the live communications may only involve the authenticators observingthe sounds and images related to the requestor. The communication mayoccur solely between the requestor and the authenticator or anindividual or device associated with the authentication system(administrator or device) may also be involved in monitoring thecommunication. This data may be presented to the authenticatorssimultaneously as a group (e.g. in a conference call) or may bepresented to each authenticator individually either in parallel or in asequential order. The communication between the requestor and theauthenticator may have a set amount of time, or may end when theauthenticator indicates the authenticator has enough information to makean evaluation.

If the user account was configured for self-authentication, theauthentication engine may initiate communications with the registereduser through primary and secondary user devices calibrated to the user'saccount during onboarding. The authentication engine may make anoutbound communication connection to the user's primary calibrateddevice, such as a mobile phone. Once connected, the authenticationengine may then prompt the user, by means of his primary device, forinformation used to select one or more of the user's secondary devices,such as a nickname for each device, or the authentication engine mayautomatically select one or more of the user's secondary devices. Theauthentication system may then transmit communications to the user'ssecondary device, such as images, sound or voice, or questions. Therequestor must have access to the one or more secondary devices, (e.g.the requestor may need to be in close proximity to the devices) and therequestor must have logon credentials for the devices, to transfer thereceived data from the secondary devices to the primary device. Thetransfer of information from the secondary device may be performed bymeans such as repeating the information into a microphone on the primarydevice, taking a photo of the data with the primary device, typing theinformation into the primary device, or transmitting the data to theprimary device using one or more wireless modalities including, but notlimited to, Bluetooth, Near Field Communication (NFC), radio frequencyidentification (RF Id), or WiFi. The data sent to a secondary device mayalso be in the form of a question, and the user may need to input theanswer into the primary device using such means as described. Once theprimary device receives the transferred data, the device may communicatea confirmation to the authentication engine to successfully complete theprocess, either automatically, if the device has been calibrated to doso, or manually via input from the user required to communicate theconfirmation.

Once the verification information is presented to the one or moreauthenticators, the authentication engine may receive authorizationinput 422 from the authenticators regarding the requestor's identity.Each authenticator may decide to confirm or deny the requestor'sidentity as the registered user and specify the level of confidence inthe decision. The authenticator's decision and confidence level may beinput to the authenticator device by various means, such as a keypad,mobile app, speech, text message, email, a graphical interface, or othersuch means, and the authenticator device communications the decision andconfidence level to the authentication engine. In one exampleembodiment, the authentication engine may be an interactive voiceresponse (IVR) device in which the authenticators may interact with theIVR using a telephone keypad or by speech recognition through theauthenticator device, such as a mobile phone, to indicate theauthenticator's decision. In another embodiment, an authenticator maycontact a human representative to indicate the authenticator's decision.Furthermore, the requestor may or may not witness the decision of anauthenticator, or even be notified of an authenticator's decision. Forexample, if a conference call with the requestor is the method topresent data to the authenticator, the authenticator may express hisdecision with the requestor still on the call or may wait until therequestor leaves the call to express his decision. The authenticator mayonly have a certain period of time in which to provide theauthenticator's response. For example, the authenticator may need toexpress his decision before leaving a conference call or may havefifteen minutes after the end of a conference call to communicate adecision to the authentication engine using another means, such as atext message.

After receiving the authorization input from the authenticators, theauthentication engine may access a decision 424 on the identity of therequestor. The decision may be based on evaluation algorithms performedat the authentication engine using some or all of the receivedresponses. The decision may allow the requestor to access all thesecured resources protected by the system, a portion of the securedresources, or none of the secured resources. The decision may also allowthe requestor to access the protected resources for one transaction, fora determined number of transactions, or allow ongoing access for aspecific period of time.

Confidence Scoring

FIG. 5 is a flow diagram of an example evaluation algorithm usingconfidence scores. A requestor 205, by means of device 210, attempt tomake an online transaction which requires authentication to accessprotected virtual or physical resources. The requestor's authenticationrequest 512 may be received at the authentication engine 140 to initiatethe authentication process. After receiving the authentication request,the authentication engine may retrieve confidence levels and thresholds514, which define the acceptable statistical and probabilistic risk offraudulent access to the protected resources of the system. Theauthentication engine may then retrieve user data and authenticatorrecords 516 from memory accessible from the authentication engine. Theauthenticator records may contain information in regards to one or moreauthenticators configured to confirm the requestor's identity as theuser. This information may include the methods for the authenticationengine to contact an authenticator, an authenticator's relationship tothe user, the last time an authenticator communicated with the user, howfrequent the authenticator communicates with the user, and data that theauthentication engine may present to the authenticator to confirm theuser's identity. The information may also include data that theauthentication engine may present to the authenticator to confirm theauthenticators own identity.

Prior to selecting authenticators to confirm the requestor's identity,the authentication engine may generate confidence scores for eachauthenticator 518. The confidence scores may be calculated using avariety of methodologies, including statistics, probabilities, or othermeans. The confidence scores may be generated by retrieving storedconfidence scores or calculating confidence scores in real-time 518. Ahigh degree of confidence may be assigned to the authentication of therequestor if the authenticator confirms the identity of the requestorand the authenticator is considered to the “trusted” based on a hightrust score. In order to calculate the trust score of an authenticator,the authentication engine may first collect information regarding theauthenticator. The information may be from the authenticator recordingcorresponding to the authenticator, including images, voice, video,forensic, or other data, which can be compared against data collectedduring the authentication process. For example, during theauthentication process an image or voice sample may be taken during avideo or phone call with the authenticator, and if it matches the imageor voice print of the authenticator stored in the authenticator record,the trust score for the authenticator may be increased. In anotherexample, the authenticator may be asked questions and the answers anddepending on how the answers compare in correctness compared toinformation in the authenticator record or information retrieved from acredit reporting agency database, and the quality of the questions, anauthenticator's trust score may be adjusted. Furthermore, theauthentication engine may access social or professional network sites,such as considering the degree contact ranking (e.g. first degreecontact) of the authenticator and the user on LinkedIn and frequency ofcontact, or whether the authenticator is in the user's “friends” and“family” circles on Google+, and the trusted score may be adjustedaccordingly. The authentication engine may also consider whether theauthenticator is also a user of the authentication system or is anauthenticator for another user of the system, and evaluate informationknown about the authenticator in regards to those accounts (e.g.,accuracy in other authentication transaction or confidence scoresgenerated in regards to other accounts). After calculating a confidencescore from each authenticator based on such information, theauthentication engine may select authenticators based on confidencelevels thresholds 520 (e.g. confidence score above confidence levelthreshold required for the requested transaction).

The authentication engine may then request the selected authenticatorsto review data to confirm the requestor's identity 522. After reviewingthe data, each authenticator may confirm or deny that the requestor isthe user and may indicate a level of certainty in their decision. Theauthentication engine may then generate a total confidence score on theidentity of the requestor based on the response of all theauthenticators 524, including both the confirm/deny response and thelevel of certainty. The authentication engine may also considering otherfactors to adjust the confidence score, such as the method that therequestor was contacted (e.g. communicating with the requestor overvideo instead of phone may increase the confidence score), or theconfidence score calculated for the particular authenticator (e.g.higher confidence score for authenticator increases the confidence scorefor the confirmation).

The authentication engine may then adjust the confidence scores based onother factors apart from the response from the authentications. Theauthentication engine may request that the requestor answer questionsfrom the user's data record 526, and may adjust the confidence scorebased on quality of questions and correctness of answers 528. Theauthentication engine may also review additional data availableregarding the requestor 530, such as comparing fingerprints, DNA, voiceprints, images, video, comparing the data to samples stored for theuser, and adjust the confidence the confidence score based on theresults and quality of the data 532. Once all the data is considered,and confidence scores calculated and adjusted accordingly, theauthentication engine may compare the confidence score to a confidencelevel threshold for confirming the requestor's identity as the user 534.Based on this comparison, the requestor may be denied access 536 orallowed access 538 to the protected resources.

In alternative embodiments, the authentication engine may utilize anevaluation algorithm that may consider the responses from all or a subset of the one or more authenticators. The algorithm may determinewhether to allow access to the requestor based solely on the number ofauthenticators that confirmed the requestor's identity as the registereduser and their level of confidence in their decision. For example, ifmore than 90% of the authenticators confirm the requestor's identity,then the requestor may be allowed access. If there is more than oneauthenticator, the algorithm may instead weigh the decisions of eachauthenticator, such that the decisions of some authenticators may havemore weight than other authenticators. The authenticators may be weighedbased on factors, such as having a stronger relationship with the useror the mode of confirming the requestor's identity (e.g. having a videoconference with the requestor instead of receiving a text message).

The evaluation algorithm may also consider additional data stored inmemory 426 accessible to the authentication engine when analyzing therequestor's identity. For example, a voice print or image of therequestor may be collected during a call with the authenticator andcompared with a voice print or image of the registered user storedduring onboarding or from other successful authentication sessions. Inaddition, the collected voice print may be analyzed for accents,inflections, words, tones that may support or reduce the likelihood thatthe requestor is the registered user or the collected image may beanalyzed for markings, eye color, or hair color. A third-party servicemay also be used to analyze collected data (e.g. fingerprints, dentalrecords) against data collected during the onboarding process, or withinother successful authentication sessions, or in other public or privaterecords for the user, such as from the user's medical files or otherforensic files, and communicate the results back to the authenticationengine. In another example, the requestor may respond to one or moresecurity questions, which may be considered by the evaluation algorithm.Such additional data may be included in the calculation of theconfidence scores or may be considered in conjunction with theconfidence scores. The additional data may be so compelling, forexample, DNA collected from the requestor during the authenticationprocess matching DNA collected from the user during the onboardingprocess, that the additional may be considered alone to confirm therequestor's identity as the user.

Analytics for Authenticators

Information related to authentication test/factors used in thecalculation of a trust score, including historical information regardingpast authentication processes in which the authenticator was used toverify the requestor/user can be used to improve the quality of thetrust scoring process applied to the authenticator. For example, ananalytics tool (such as a web analytics tool or BI tool) may producevarious metrics such as measures of each authenticator's responsivenessand authentication success based on a combination of other criteria(e.g. environment variables associated with the authenticator), andfilter these results by time of the day or time period or means ofcontacting the authenticator, such as by SMS, email, voice, video. Suchmeasures can be viewed per authenticator to help improve the quality ofthe computation of confidence and trust scores because the results maybe aggregated across a multitude of authenticators.

Furthermore, analytics data for a calculated trust/confidence score foran authenticator can be aggregated per type of device. For example, itcould be of interest to know which types of devices or contactmechanisms are most or least conducive to a high trust score calculationfor an authenticator, or on the contrary, applied to a low trust scorecalculation for an authenticator.

Trusted Platform Module and Binding

The authentication engine/agent may be implemented as a Trusted PlatformModule (TPM) executing on computing device 150. The TPM may provide asecure platform to integrate the authentication software, or a portionthereof, for performing authentication of the requestor. For example,the TPM may provide secure, encrypted storage for records regardingauthenticating the user, such as authenticator records or other datarecords, to maintain a level of integrity or “trust” that these recordshave not be illicitly or mistakenly accessed or altered. The TPM mayalso provide platform integrity, such that information communicated tothe authentication engine (e.g. from the user or authenticators),including collecting data to onboard the user or data confirming ordenying a user's identity, may be processed in an environment that canbe trusted that the data was not tampered with prior to the completionof processing. Furthermore, in a system where passwords are used in partfor the user to access resources, and the authentication process is onlyused in certain situations (e.g. specific transaction or when a passwordexpires), the TPM may secure the integrity of the passwords fromattacks, such as automated dictionary attacks, and secure the integrityof the environment when the user enters a new password, pincode, orother such data. The use of the TPM may be considered when calculatingthe trust score for a transaction, that is, authenticating a user on anauthentication engine implemented as a TPM would result in a highertrust score than on a less secure platform. In this way, the use of theTPM would increase the overall confidence that the user is who he/shepurports by binding the user to the device.

Similarly, a SIM card is uniquely identifiable and typically specific toa particular user. For instance, a mobile phone user needs often needssome form of identification to obtain a SIM card for activation. Theconfidence score could be increased if the system determines that theSIM card successfully matches the user's credentials. In addition, aserial number associated with the mobile device on which the SIM card isoperating can be used to increase the overall trust score for theauthentication process for the user. In the alternatively, a serialnumber that does not match the SIM card could decrease the confidencescore.

While this invention has been particularly shown and described withreferences to example embodiments thereof, it will be understood bythose skilled in the art that various changes in form and details may bemade therein without departing from the scope of the inventionencompassed by the appended claims. While specific example onboardingand authentication processes are described herein, those of ordinaryskill in the field of trusted computing will appreciate that suchprocesses are exemplary and similar processes are applicable andencompassed by the appended claims.

What is claimed is:
 1. An interactive voice response (IVR) systemconfigured to authenticate a requestor to perform transactions whichrequire accessing secure resources protected by the system, the IVRcomprising: a first application configured to send a voice request forauthenticating a requestor; an IVR device coupled to a telephony serverconfigured to: interpret the voice request received from the firstapplication in order to retrieve at least one record corresponding to atleast one authenticator, and transmit information from the at least onerecord to a corresponding at least one authenticator; a secondapplication configured to receive the information sent to the at leastone authenticator from the IVR device, the second application furtherconfigured to send a voice response from the at least one authenticatorto the IVR device based on the information; and the IVR device furtherconfigured to interpret the voice response from the second applicationin order to determine whether to allow the user access to the secureresources based on the voice response.
 2. The IVR system of claim 1wherein one or more of the authenticators is a third-party human trusteewith a relationship to the user.
 3. The IVR system of claim 1 whereinone or more of the authenticators is the user by means of a one or morecalibrated devices.
 4. The IVR system of claim 1 wherein sendinginformation from the at least one record includes sending at least oneof the following: text, images, voice, video, or forensic data.
 5. TheIVR system of claim 1 wherein the one or more records contains at leastone of: contact information, relationship information and verificationinformation.
 6. The IVR system of claim 1 wherein sending informationfrom the at least one record includes questions presented to therequestor and the requestor's corresponding answers.
 7. The IVR systemof claim 1 further comprising sending information not in the at leastone record, but collected from the requestor in live or recorded.
 8. TheIVR system of claim 1 further comprising sending information not in theat least one record, but collected from one or more of the following:requestor's electronic files, social or professional networking site, orone or more credit reporting agency databases.
 9. The IVR system ofclaim 1 wherein the at least one authenticator determines whether therequestor is the user based on a conference call with the requestor. 10.The IVR system of claim 1 wherein determining whether to allow the useraccess to the protected resources is based on a confirm or deny responseand a level of certainty from the one or more authenticators.
 11. TheIVR system of claim 1 where determining whether to allow the user accessto the protected resources is based on calculating a confidence score.12. The IVR system of claim 1 wherein the IVR device is implemented as aTrusted Platform Module.
 13. A computer-implemented method forself-authenticating a user to perform transactions which requireaccessing protected resources, the computer-implemented methodcomprising: calibrating a primary device and one or more secondarydevices to be contacted for purposes of self-authenticating the user;receiving a communication at the primary device in response selecting atleast one of the one or more secondary devices to transmitauthentication data; receiving that authentication data at the at leastone secondary device wherein in response transferring the authenticationdata to the primary device; and reporting a confirmation from theprimary device of receiving the authentication data.
 14. Thecomputer-implemented method of claim 13 wherein the authentication dataor other data is at least one of images, sound, video, or text.
 15. Thecomputer-implemented method of claim 13 wherein the authentication datareceived by the at least one secondary device is in the form of aquestion and, instead of transferring the authentication data to theprimary device, transferring an answer to the question.
 16. Thecomputer-implemented method of claim 13 wherein transferring theauthentication data comprising transferring by at least one of:repeating the information into a microphone on the primary device,taking a photo of the data from the primary device, typing theinformation into the primary device, or transferring the data to theprimary device using one or more wireless modalities.
 17. An interactivevoice response (IVR) system for self-authenticating a user to performtransactions which require accessing protected resources, the IVRcomprising: an IVR device coupled to a telephony server configured toconfigured to calibrate a primary application and one or more secondaryapplication, the IVR device configured to send a voice request to theprimary application for providing at least one identified secondaryapplication and transmitting authentication data, in the form of sound,to the at least one identified application, if the at least oneidentified secondary applications matches at least one of the one ormore secondary applications; the primary application calibrated torespond to the voice request from the IVR device by sending the at leastone identified secondary application to the IVR device; the one or moresecondary applications calibrated to receive the authentication data, inthe form of sound, from the IVR device, the one or more secondaryapplications calibrated to present the authentication data in a form tobe transferred to the primary application; and the primary applicationfurther calibrated to receive the authentication data transferred fromthe at least one identified secondary application and in response send avoice confirmation to the IVR device.
 18. The data processing system ofclaim 17 wherein the authentication data received by the at least onesecondary device is in the form of a question and, instead oftransferring the authentication data to the primary device, transferringan answer to the question.
 19. The data processing system of claim 18wherein transferring the authentication data comprising transferring byat least one of: repeating the information into a microphone on theprimary device, taking a photo of the data from the primary device,typing the information into the primary device, or transferring the datato the primary device using wireless modalities.